Ex No: 1 PROBLEM STATEMENT

AIM: To prepare a PROBLEM STATEMENT for any project.

REQUIREMENTS:

 Hardware Interfaces

 Pentium(R) 4 CPU 2.26 GHz, 128 MBRAM

 Screen resolution of at least 800 x 600 required for proper and complete

viewing of screens. Higher resolution would not be a problem.

 CD ROM Driver

 Software Interfaces

 Any Windows-based operating system

 WordPad or Microsoft Word

THEORY:

The problem statement is the initial starting point for a project. It is basically a

one-to-three-page statement that everyone on the project agrees with that describes

what will be done at a high level. The problem statement is intended for a broad

audience and should be written in non- technical terms. It helps the non-technical and

technical personnel communicate by providing a description of a problem. It doesn't

describe the solution to the problem.

The input to requirement engineering is the problem statement prepared by

customer. It may give an overview of the existing system along with broad expectations

from the new system.

The first phase of requirements engineering begins with requirements elicitation i.e.

gathering of information about requirements. Here, requirements are identified with the

help of customer and existing system processes. So, from here begins the preparation of

problem statement.

So, basically a problem statement describes what needs to be done without

describing how.

Conclusion: The problem statement was written successfully by following the steps

described above.

Ex No: 2 SYSTEM REQUIREMENT SPECIFICATION

AIM: Understanding an SRS.

REQUIREMENTS:

1. Hardware Requirements:

 PC with 300 megahertz or higher processor clock speed recommended;

233 MHz minimum required.

 128 megabytes (MB) of RAM or higher recommended (64 MB minimum

supported)

 1.5 gigabytes (GB) of available hard disk space

 CD ROM or DVD Drive

 Keyboard and Mouse (compatible

pointing device).

2. Software Requirements:

 Rational Rose, Windows XP,

THEORY:

An SRS is basically an organization's understanding (in writing) of a customer

or potential client's system requirements and dependencies at a particular point in time

(usually) prior to any actual design or development work. It's a two-way insurance

policy that assures that both the client and the organization understand the other's

requirements from that perspective at a given point in time.

The SRS document itself states in precise and explicit language those functions

and capabilities a software system (i.e., a software application, an e-commerce web

site, and so on) must provide, as well as states any required constraints by which the

system must abide. The SRS also functions as a blueprint for completing a project with

as little cost growth as possible. The SRS is often referred to as the "parent" document

because all subsequent project management documents, such as design specifications,

statements of work, software architecture specifications, testing and validation plans,

and documentation plans, are related toit.

It's important to note that an SRS contains functional and nonfunctional

requirements only; it doesn't offer design suggestions, possible solutions to technology

or business issues, or any other information other than what the development team

understands the customer's system requirements to be.

A well-designed, well-written SRS accomplishes four major goals:

 It provides feedback to the customer. An SRS is the customer's assurance that

the development organization understands the issues or problems to be solved

and the software behaviour necessary to address those problems. Therefore, the

SRS should be written in natural language (versus a formal language, explained

later in this article), in an unambiguous manner that may also include charts,

tables, data flow diagrams, decision tables, and soon.

 It decomposes the problem into component parts. The simple act of writing

down software requirements in a well-designed format organizes information,

places borders around the problem, solidifies ideas, and helps break down the

problem into its component parts in an orderly fashion.

 It serves as an input to the design specification. As mentioned previously, the

SRS serves as the parent document to subsequent documents, such as the

software design specification and statement of work. Therefore, the SRS must

contain sufficient detail in the functional system requirements so that a design

solution can be devised.

 It serves as a product validation check. The SRS also serves as the parent

document for testing and validation strategies that will be applied to the

requirements for verification.

SRSs are typically developed during the first stages of "Requirements

Development," which is the initial product development phase in which information is

gathered about what requirements are needed--and not. This information-gathering

stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a

return-on-investment (ROI) analysis or needs analysis of the customer or client's

current business environment. The actual specification, then, is written after the

requirements have been gathered and analysed.

SRS should address the following:

The basic issues that the SRS shall address are the following:

a) Functionality. What is the software supposed todo?

b) External interfaces. How does the software interact with people, the system‘s

hardware, other hardware, and other software?

c) Performance. What is the speed, availability, response time, recovery time of

various software functions, etc.?

d) Attributes. What are the portability, correctness,

maintainability, security, etc. considerations?

e) Design constraints imposed on an implementation. Are there any required

standards in effect, implementation language, policies for database integrity,

resource limits, operating environment(s)etc.?

Characteristics of a good SRS

An SRS should be

 Correct

 Unambiguous

 Complete

 Consistent

 Ranked for importance and/or stability

 Verifiable

 Modifiable

 Traceable

Correct - This is like motherhood and apple pie. Of course you want the specification

to be correct. No one writes a specification that they know is incorrect. We like to say -

"Correct and Ever Correcting." The discipline is keeping the specification up to date

when you find things that are not correct.

Unambiguous - An SRS is unambiguous if, and only if, every requirement stated

therein has only one interpretation. Again, easier said than done. Spending time on this

area prior to releasing the SRS can be a waste of time. But as you find ambiguities - fix

them.

Complete - A simple judge of this is that is should be all that is needed by the software

designers to create the software.

Consistent - The SRS should be consistent within itself and consistent to its reference

documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop"

in another.

Ranked for Importance - Very often a new system has requirements that are really

marketing wish lists. Some may not be achievable. It is useful provide this information

in the SRS.

Verifiable - Don't put in requirements like - "It should provide the user a fast response.

"Another of my favourites are - "The system should never crash." Instead, provide a

quantitative requirement like: "Every key stroke should provide a user response within

100milliseconds."

Modifiable - Having the same requirement in more than one place may not be wrong -

but tends to make the document not maintainable.

Traceable - Often, this is not important in a non-politicized environment. However, in

most organizations, it is sometimes useful to connect the requirements in the SRS to a

higher- level document. Why do we need this requirement?

A sample of basic SRS Outline

1. Introduction

 Purpose

 Document conventions Intended

audience

 Additional information

 Contact information/SRS team members

References

2. Overall Description

 Product perspective

 Product functions

 User classes and characteristics

 Operating environment

 User environment

 Design/implementation constraints

 Assumptions and dependencies

3. External Interface Requirements

 User interfaces

 Hardware interfaces

 Software interfaces

 Communication protocols and interfaces

4. System Features

 System feature A

 Description and priority

 Action/result

 Functional requirements

 System feature B

5. Other Non-functional Requirements

 Performance requirements

 Safety requirements

 Security requirements

 Software quality attributes

 Project documentation

 User documentation

6. Other Requirements

Appendix A: Terminology/Glossary/Definitions list Appendix B: To be determined

Conclusion: The SRS was made successfully by following the steps described above.

Ex No: 3 LIBRARY MANAGEMENT SYSTEM

PROBLEM DEFINITION

The library management system is software, which automates the job of a librarian.

The user can inquire about the availability of a book in which he can search by entering the

author’s name or by entering the title of the book.

The user can borrow a book. He must provide the username and the card number, which is unique

and confidential to each user. By confirming the authenticity of a user, the library management

system provides information about the number of books already borrowed by the user and by

referring to the database whether the user can borrow books or not. The library management

system allows the user to enter the title and the author of the book and hence issues the book if it

is available.

By entering the user details and the book details the user can return the borrowed book.

SYSTEM REQUIREMENTSPECIFICATION

INTRODUCTION

Purpose

The purpose of this SRS is to describe the requirements involved in developing a Library

management system. The intended audience is any person, who wants to inquire, borrow and

return the books.

Scope

 The product is titled Library Management System.

 The product will perform the following tasks Enquire about the availability of books.

 Borrow books if available.

 Return the borrowed books.

Definitions, Acronyms and Abbreviations DBMS – Database Management System.

References

IEEE standard 830-1998 recommended practice for Software Requirements Specifications-

Description.

Overview

The SRS contains an analysis of the requirements necessary to help easy design.

The overall description provides interface requirements for the Library Management

System, product perspective, hardware interfaces, software interfaces, communication

interface, memory constraints, product functions, user characteristics and other constraints.

Succeeding pages illustrate the characteristics of typical naïve users accessing the system

along with legal and functional constraints enforced that affect Library Management System

in any fashion.

THE OVERALLDESCRIPTION

Product perspective

Hardware interfaces

Hard disk: The database connectivity requires a hardware configuration that is on-line. This

makes it necessary to have a fast database system running on high rpm hard disk permitting

complete data redundancy and back-up systems to support the primary goal of reliability.

The system must interface with the standard output devise, keyboard and mouse to

interact with this software. Software interfaces

 Back End: MS-Access 2007

 Front End: Microsoft Visual Basic 6.0

 Memory Constraints

 No specific constraints on memory.

 Operations

The software allows three modes of operations 2.2.1.4.1.1 Enquire about the availability

and status of books. By extracting the username and password the software allows the

user to borrow a maximum of three books. By extracting the username and password the

software allows the user to return the borrowed books. Product Functions

 Enquire about the availability and status of books.

 Search the availability of book by entering the title of the book.

 Search the availability of book by entering the author of the book.

 The software validates the authentic user by extracting their user name and

password.

After the validation of the user software allows the user to borrow a maximum of three

books based on the number of books which where already borrowed.

After the validation of the user software allows the user to return the books, which where

borrowed.

User characteristics

The intended users of this software need not have specific knowledge as to what is the

internal operation of the system. Thus, the end user is at a high level of abstraction that

allows easier, faster operation and reduces the knowledge requirement of end user

The Product is absolutely user friendly, so the intended users can be the native users.

The product does not expect the user to possess any technical background. Any person who

knows to use the mouse and the keyboard can successfully use this product.

Constraints

The user has a unique username and password, there are no options to retrieve a password or

username in case it is forgotten or lost hence the user is requited to remember or store the

username and password.

SPECIFICREQUIREMENTS

Logical Database Requirements

The system should contain databases that include all necessary information for the product

to function according to the requirements. These include relations such as user details and

book details.

The user details refer to the information such as name, card number, no. of books borrowed,

the title and the name of the author of the books that were borrowed.

The book details refer to the information such as the title of the book, author availability status

and the number of copies that is available.

FRONT – ENDDESCRIPTION

The library management system is automated library system where the user can

search for the book by either entering the details of the book or the author’s name. By

entering the username and the password the software, by checking the number of books that

are already borrowed enables us to borrow a maximum of three books. And by entering the

username and password (card number), which is unique, the user can return the books.

BACK – ENDDESCRIPTION

The library management system consists of two tables. One contains the student

details such as the name, card number that is the password, title and the author of the three

books, which could be borrowed. The book details consist of the title of the book, number of

copies, author and the availability status.

DATASTRUCTURES

BOOK DETAILS

FIELD NAME

TYPE

CONSTRAINTS

REGISTER_NO

NUMBER

NOT NULL

BOOK_ID

NUMBER

NOT NULL

ISSUE_DATE

DATE/TIME

RETURN_DATE

DATE/TIME

BOOK_NAME

TEXT

STUDENT DETAILS

FIELD NAME

TYPE

CONSTRAINTS

REGISTER_NO

NUMBER

NOT NULL

FNAME

TEXT

NOT NULL

LNAME

TEXT

GENDER

TEXT

DEPT

TEXT

PASSWORD

TEXT

NO_OF_BOOKS

NUMBER

DATA FLOWDIAGRAM

TESTING:

FORM NAME

INPUT

EXPECTED

OUTPUT

ACTUAL

OUTPUT

STATUS

MAIN MENU

FORM

Menu Option

Show

required

Form

Required

Form was

displayed

Pass

MEMBERSHIP

FORM

Member

details are

entered

Create new

member account

New Account

was created

Pass

Member ID

and password

If password is

correct, login.

Member

authenticated

for future

operations.

Pass

ISSUE FORM

Book ID

If books issued is

less than three,

issue the book.

Book issued

Pass

RETURN/REISSUE

FORM

Book ID

Book returned/

reissued

Book

returned/

Reissued

Pass

BOOK ENQUIRY

Book Name

Book details are

displayed

Book details

are displayed

Pass

SAMPLE FORMS

MAIN MENU FORM

MEMBERSHIP FORM

ISSUE FORM

RETURN/REISSUE FORM

BOOK ENQUIRY FORM

RESULT:

Thus, the online Library System was implemented using the specified front end and back

end tools.

Ex No: 4 AUTOMATED BANKING SYSTEM

PROBLEM DEFINITION

To develop an automated banking system, which is required to perform the following functions:

The customer logs into the system using card number and pin number. The system checks for

validation.

The system queries the customer for the type of account either fixed deposit or credit

account. After getting the type of account the system shows the balance left.

The system queries the customer for the transaction type either withdrawal or deposit and the

required amount. The user enters the amount and the

transaction if carries out

SRS DOCUMENT FOR AUTOMATED BANKINGSYSTEM

INTRODUCTION

Purpose

The purpose of this SRS is to describe the requirements involved in developing an

Automated Banking System (ABS). The intended audience is any person who wants to

create account.

To withdraw or deposit either in fixed deposit or credit account.

Scope

The product is titled Automated Banking System (ABS).

The product will perform the following tasks

Allow a new user to create an account, either fixed or credit account by entering the details

and by depositing an initial amount.

Allow the existing user to enter his account details like card number, pin number and account

type to view his balance.

Allow the existing user to deposit an amount by entering the amount to be deposited after

the balance had been viewed. Allow the existing user to withdraw an amount by entering the

amount to be withdrawn after the balance had been viewed. The primary benefits expected

of the system are: user friendly, continuous connectivity without failure, fault tolerant and

involves lesser manpower.

Definitions, Acronyms and Abbreviations ABS: Automated

Banking System.

References

IEEE standard830-1998recommended practicefor Software

Requirements Specifications-Description.

IEEE SoftwareRequirements Specifications

Templatehttp://www.cas.master.ca/~carette/SE3M04/2

003/files/ srs_template.doc

Overview

 The SRS contains an analysis of the requirements necessary to help easy design.

 The overall description provides interface requirements for the Banking system, product

perspective, hardware interfaces, software interfaces, communication interface, memory

constraints, product functions, user characteristics and other constraints.

 Succeeding pages illustrate the characteristics of typical naïve users accessing the system

along with legal and functional constraints enforced that affect banking system in any

fashion.

THE OVERALLDESCRIPTION

Product perspective Hardware interfaces

Hard disk: The database connectivity requires a hardware configuration that is on-line. This

makes it necessary to have a fast database system (such as any RDBMS) running on high

rpm hard-disk permitting complete data redundancy and backup systems to support the

primary goal of reliability.

The system must interface with the standard output device, keyboard and mouse to interact with

this software.

Software interfaces

Back End: MS Access2007

Front End: Microsoft Visual Basic 6.0

Operations

The user can create a new account.

The existing user can access his account and view his balance by entering his details.

The user can deposit and withdraw money from his account.

Product Functions Creating a New Account

The user should provide his personal details to facilitate the bank clerk to create a new

account. The user should provide:

 Customer Name.

 Customeraddress.

 Required account type.

 Pin Number.

 Initial deposit.

 Operating with created account

The user should be able to operate with his new account after:

 Entering card number.

 Entering pin number.

 Entering the account type, transaction type and amount involved in the transaction.

User characteristics

The intended users of this software need not have specific knowledge as to what is the

internal operation of the system. Thus the end user is at a high level of abstraction that

allows easier, faster operation and reduces the knowledge requirement of end user

The Product is absolutely user friendly, so the intended users can be the naïve users.

The product does not expect the user to possess any technical background. Any person who

knows to use the mouse and the keyboard can successfully use this product.

Constraints:

At the time of creating the new account, each user gives a pin number and is provided with a

unique card number that must be used for further transactions. Hence the user is required to

remember or store these numbers carefully.

At the time of creating the new account, the initial deposit should not be less than the specified

amount.

SPECIFIC REQUIREMENTS

Logical Database Requirements

The system should contain databases that include all the necessary information for the

product to function according to the requirements. These include relations such as Customer

Details and Account Details.

Customer details refer to the customer’s name and address. Account details of the customer

include the card number, account type, transaction type and the pin number given by the

user to be used at the time of the transaction at the bank.

FRONT – ENDDESCRIPTION

The front end for the Automated Banking System (ABS) is designed using Microsoft

Visual Basic 6.0. The front end contains a user-friendly interface. The first form contains a

welcome screen that provides an option for the user to either crate a new account or to

operate through an existing account. The “create account” module contains a provision to

create a new account after collecting the customer name, address and other details. The card

number and pin number of the user is obtained every time there is a transaction. The user is

requested to select the required type of transaction and the amount involved in the

transaction.

BACK – ENDDESCRIPTION

The Automated Banking System (ABS) database contains only one table. It

correlates a unique card number, customer name, account type, pin number and the balance.

DATASTRUCTURES

ACCOUNT DETAILS

FIELD NAME

TYPE

CONSTRAINTS

NAME

TEXT

ACC_NO

AUTONUMBER

NOT NULL

AGE

NUMBER

GENDER

TEXT

PHONE_NO

NUMBER

PASSWORD

TEXT

BALANCE

NUMBER

DATA FLOWDIAGRAM:

TESTING

FORM NAME

INPUT

EXPECTED

OUTPUT

ACTUAL OUTPUT

STATUS

MAIN MENU

FORM

Menu Option

Required Form must

Required form was

displayed

Pass

displayed

ACCOUNT

User Details are

entered

Create a new account

New account was

created

Pass

CREATION

FORM

Account ID and

password are entered

If passwords match,

User permitted to

perform further

operations

Pass

WELCOME FORM

User can select

deposit, withdraw or

view balance

Show Deposit form

or Withdraw form or

view balance

Deposit form or

withdraw form or

balance is displayed

Pass

DEPOSIT

Amount to be

Deposit amount

Amount was

Pass

FORM

deposited is entered

deposited

WITH DRAW

FORM

Amount to be

withdrawn is Entered

Withdraw amount

Amount was

withdrawn

Pass

Queries

for

details

Queries

for

details

Commits

transaction

Enters

a/c

number

Update

Checks

for

availab

ility

a/cdetails

Generates

error

report

about

new

transaction

User

Administrator

SAMPLEFORMS

MAINMENUFORM

ACCOUNT CREATION FORM

WELCOME FORM

DEPOSIT FORM

WITHDRAW FORM

RESULT

Thus, the requirements involved in developing an Automated Banking System was

completed successfully.

Ex No: 5 AIRLINE RESERVATION SYSTEM

PROBLEM DEFINITION

Ticket reservation system for airlines has to be developed.

The system developed should contain the following features

 The system should contain the following features

 Search for information about the flight by means of flight number and destination

 While displaying information about the flight it has to provide availability of seats.

 While reserving tickets the system obtains following information from the user

o Passenger Name, Sex, Age, Address.

o Credit Card Number, Bank Name.

o number, Flight name, Date of Journey and number of tickets to be booked.

 Based on the availability of tickets, the ticket has to be issued. The ticket issued should

contain the following information –ticket number, flight no, flight name, date of journey,

number of passengers, sex, age and departure time.

 Cancellation of booked tickets should be available.

SRS DOCUMENT FOR AIRLINE RESERVATIONSYSTEM

INTRODUCTION

Purpose

The purpose of this SRS is to describe the requirements involved in developing a Airline

Reservation system (ARS).

The intended audience is any person who wants to reserve or cancel tickets or to check the

availability of Airline tickets

Scope

The product is titled Airline Reservation system (ARS).

The product will perform the following tasks

The software that is being developed can be used to check the availability of the flight tickets for

the specified flight, destination and date of journey

If the tickets are available to the users needs and specification, then the software provide a

facility to book the tickets.

If the passengers want to cancel the tickets, he can use the cancellation module of the Airline

Reservation System.

Definitions Acronyms and Abbreviations ARS: Airline Reservation System.

References

IEEE standard 830-1998 recommended practice for Software

Requirements Specifications-Description.

Overview

The SRS contains an analysis of the requirements necessary to help easy design.

The overall description provides interface requirements for the Airline Reservation system,

product perspective, hardware interfaces software interfaces,, communication interface,

memory constraints, product functions, user characteristics and other constraints.

Succeeding pages illustrate the characteristics of typical naïve users accessing the system

along with legal and functional constraints enforced that affect Airline Reservation system

in any fashion.

THE OVERALLDESCRIPTION

Product perspective

Hardware interfaces

Hard disk: The database connectivity requires a hardware configuration with a fast database

system running on high rpm hard-disk permitting complete data redundancy and back-up

systems to support the primary goal of reliability.

The system must interface with the standard output device, keyboard and mouse to interact with

this software.

Software interfaces

Back End: MS Access2007

Front End: Microsoft Visual Basic 6.0

Operations

The user mode enables the end-users to do the end user operations like checking the availability,

reserving and cancelling of flight tickets.

Product Functions

Viewing Flight Details

The user must have the access up-to-date information about the flights including

 Flight number

 Flight Name

 Flight route (Start and Destinationstations)

 Flight timings

 Seat availability.

 Reserving Tickets

The user must be able to reserve tickets after selecting

 Flight number

 Flight Route Cancelling Tickets

The user must be able to cancel tickets that he has earlier reserved by quoting the ticket number,

credit card number and bank name.

User characteristics

The intended users of this software need not have specific knowledge as to what is the

internal operation of the system. Thus, the end user is at a high level of abstraction that

allows easier, faster operation and reduces the knowledge requirement of end user

The Product is absolutely user friendly, so the intended users can be the naïve users.

The product does not expect the user to possess any technical background. Any person who

knows to use the mouse and the keyboard can successfully use this product.

Constraints

At the time of reservation, each user is provided a unique ticket number that must be used

for further operation like cancellation. Hence the user is required to remember or store this

number carefully.

SPECIFICREQUIREMENTS

Logical Database Requirements

The system should contain databases that include all necessary information for the product

to function according to the requirements. These include relations such as flight details,

reservation details, and cancellation details.

The user details refer to the information such as flight number and name, start and destination

stations, seat availability.

Reservation details refer to personal information that is obtained from the user

At the time of reservation, the passenger is provided a unique ticket no that could be used at the

time of cancellation.

While displaying any information about the flight it has to provide the following

information Flight no and name

Availability of seats for the particular flight

The flight timing

The passenger personal details should be obtained for reserving the tickets.

FRONT – END DESCRIPTION

The front-end for the Airline Reservation system (ARS) is designed using Microsoft

Visual Basic 6.0. The front-end contains a user- friendly interface. The first form contains a

welcome screen that provides an option for the user to select one of the following

 Enquiry

 Reservation

 Booking details

 Cancellation

In the Enquiry form the user can get details of the flight by means of either flight

name destination or date 0of journey. In the reservation form, there can book details by

entering the personal details. The ticket is displayed with details about the flight name and

number, number of passengers, ticket number, sex and age. The cancellation form helps the

user to cancel a ticket, which he had booked earlier.

BACK – ENDDESCRIPTION

The Airline Reservation system consists of two tables. One contains the flight details

such as the flight name, flight number, destination, date of journey and seats available in

each class that is referred to during enquiry. The other table has the passenger details such as

name, age, sex, credit card number, and bank name. This table is referred to at the time of

reservation or cancellation.

DATASTRUCTURES

FLIGHTDETAILS

FIELD NAME

TYPE

CONSTRAINTS

ROUTE_NAME

TEXT

NOT NULL

FLIGHT_NO

NUMBER

NOT NULL

SEATS_AVAIL

NUMBER

JOURNEY_DATE

DATE/TIME

DEP_TIME

DATE/TIME

ARR_TIME

DATE/TIME

COST

NUMBER

PASSENGER DETAILS

FIELD NAME

TYPE

CONSTRAINTS

TICKET_NO

AUTONUMBER

NOT NULL

NAME

TEXT

NOT NULL

GENDER

TEXT

ADDRESS

TEXT

CC_NO

NUMBER

NOT NULL

BANK_NAME

TEXT

NO_OF_TICKETS

NUMBER

DATA FLOWDIAGRAM

TESTING:

FORM NAME

INPUT

EXPECTED

OUTPUT

ACTUAL

OUTPUT

STATUS

MAIN MENU

FORM

Menu Option

Required form

must be displayed

Required

form was

displayed

Pass

TICKET

AVAILABILITY

FORM

Flight route or

Flight name

Flight seat

availability must

be displayed.

Flight seats

availability is

displayed.

Pass

RESERVATION

FORM

Personal

details were

entered.

Ticket must be

booked and

database updated.

Ticket was

booked and

database was

updated.

Pass

SAMPLE FORMS

MAIN MENU FORM

TICKET AVAILABILITY FORM RESERVATION FORM

CANCELLATION FORM

RESULT

Thus, the online Airline Reservations System was implemented using the specified front

end and back-end tools.

Ex No: 6 EMPLOYEE MANAGEMENT APPLICATION

PROBLEM DEFINITION

A payroll application is to be developed which is required to perform the following functions:

It must provide a user in employee mode with the details of an employee, which includes his

name, department, date of joining and salary.

It must validate a user to enter in administrator mode using password. It must provide a user

to enter in administrator mode to view or modify an employee’s details using his employee

ID. It must also allow the user to add a new employee and delete records of an existing

employee.

SRS DOCUMENT EMPLOYEE MANAGEMENTAPPLICATION

INTRODUCTION

Purpose

The purpose of this SRS is to describe the requirements involved in developing a system to

manage employee records.

The intended audience is any person who wants

To check employee details (both employee and administrator mode).

To add new employee, modify any employee’s details or delete records for the employee (only

administer mode).

Scope

 The product is titled Employee Management Application (EMA).

 The product will perform the following tasks

 Allow either an employee or an administrator to view employee details.

 Allow the administrator to add a new employee with corresponding details.

 Allow the administrator to modify the detail of an employee.

 Allow the administrator to delete the records for an employee.

Definitions, Acronyms and Abbreviations

EMA: Employee Management Application.

References

IEEE standard 830-1998 recommended practice for Software

Requirements Specifications-Description.

Overview

The SRS contains an analysis of the requirements necessary to help easy design.

The overall description provides interface requirements for the Employee Management

System, product perspective, hardware interfaces, software interfaces, communication

interface, memory constraints, product functions, user characteristics and otherconstraints.

Succeeding pages illustrate the characteristics of typical naïve users accessing the system

along with legal and functional constraints enforced that affect Employee Management

Application in any fashion.

THE OVERALLDESCRIPTION

Product perspective

Hardware interfaces

Hard disk: The database connectivity requires a hardware configuration that is on-line. This

makes it necessary to have a fast database system (such as any RDBMS) running on high

rpm hard-disk permitting complete data redundancy and backup systems to support the

primary goal of reliability.

The system must interface with the standard output device, keyboard and mouse to interact with

this software.

Software interfaces

Back End: MS Access2007

Front End: Microsoft Visual Basic 6.0

Memory Constraints

No specific constraints on memory.

Operations

The software allows two modes of operations

The administrator mode allows user to add a new employee, modify the existing

details of an employee, view the details of an employee and also delete records for an

existing employee.

Product Functions

Viewing the employee details

The user (both administrator and employee) must have the access to Upto-date information about

the employee including

 Employee Id

 EmployeeName

 EmployeeDepartment

 DateofJoining

 Salary

 Adding a new employee

The user (only in administrator mode) must be able to add a new employee by supplying the

following employee details.

 EmployeeName

 EmployeeDepartment

 DateofJoining

 Salary

 Modifying the details of an employee

 The user (only in administrator mode) must be able to modify the following details of an

existing employee.

 EmployeeName

 EmployeeDepartment

 Date ofJoining

 Salary

 Usercharacteristics

The intended users of this software need not have specific knowledge as to what is the

internal operation of the system. Thus the end user is at a high level of abstraction that

allows easier, faster operation and reduces the knowledge requirement of enduser

The Product is absolutely user friendly, so the intended users can be the naïveusers.

The product does not expect the user to possess any technical background. Any person who

knows to use the mouse and the keyboard can successfully use thisproduct.

Constraints

At the time of adding a new employee, each employee must be assigned a unique ID

number.

SPECIFICREQUIREMENTS

Logical DatabaseRequirements

There is only one database which contains all the necessary information about an employee

which includes employee ID, employee name, department, date if joining and salary.

FRONT – ENDDESCRIPTION

The front end for the Employee Management Application (EMA) is designed using

Microsoft Visual Basic 6.0. The front – end contains a user – friendly interface. It has a

welcome screen that provides an option for the user to enter in employee mode or in

administrator mode. In employee mode the user can enter the employee ID of the employee

and view his details. The user has to validate him self using password to enter in

administrator mode. In administrator mode, apart form viewing the details the user can also

add a new employee by providing details or modify the existing details using the employee

ID.

BACK – ENDDESCRIPTION

There is only one table. It correlates a unique employee ID with his name, department,

date of joining and salary.

DATASTRUCTURES

EMPLOYEE DETAILS

FIELD NAME

TYPE

CONSTRAINTS

AUTONUMBER

NOT NULL

NAME

TEXT

DEPT

TEXT

JOIN_DATE

DATE/TIME

SALARY

NUMBER

DATA FLOWDIAGRAM

TESTING:

FORM NAME

INPUT

EXPECTED

OUTPUT

ACTUAL OUTPUT

STATUS

MAIN MENU

Menu Option

Required form must

be displayed

Required Form was

displayed

Pass

ADD NEW

EMPLOYEE

Employee details

Add employee details

to database

Employee details was

updated to database

Pass

VIEW EMPLOYEE

DETAILS

Employee ID

Show employee

details

Employee details was

displayed

Pass

MODIFY

EMPLOYEE

DETAILS

Employee ID

Modify employee

Employee details was

modified

Pass

DELETE

EMPLOYEE

DETAILS

Employee ID

Delete employee

details

Employee details was

deleted from database

Pass

SAMPLE FORMS

MAIN MENU

ADD NEW EMPLOYEE

VIEW EMPLOYEE DETAILS

MODIFY EMPLOYEE DETAILS

DELETE EMPLOYEE DETAILS

RESULT

Thus, the Employee Management System was implemented using the specified front end

and back end tools.

Ex No: 7 HOSPITAL MANAGEMENT APPLICATION

PROBLEM DEFINITION

A hospital application is to be developed which is required to perform the following functions:

It must provide a user in admin mode with the details of a patient, doctor. It must provide a

user in doctor mode who can modify the details of the illness and the treatment.

SRS DOCUMENT HOSPITAL MANAGEMENTAPPLICATION

INTRODUCTION

Purpose

The purpose of this SRS is to describe the requirements involved in developing a system to

manage hospital records.

The intended audience is any person who wants To check patient and doctor

details (both doctor and administrator mode).

To add new treatment details for any particular patient according to his illness. (only doctor

mode).

Scope

The product is titled Hospital Management Application (HMA).

The product will perform the following tasks

Allow either an doctor or an administrator to view patient details. Allow the administrator to add

a new patient, doctor with corresponding details.

Allow the administrator to modify the detail of an patient, doctor. Allow the doctor to add the

records for an ongoing treatment.

Definitions, Acronyms and Abbreviations HMA: Hospital Management

Application.

References:

IEEE standard 830-1998 recommended practice for Software

Requirements Specifications-Description.

Overview

The SRS contains an analysis of the requirements necessary to help easy design.

The overall description provides interface requirements for the Hospital Management

System, product perspective, hardware interfaces, software interfaces, communication

interface, memory constraints, product functions, user characteristics and other constraints.

Succeeding pages illustrate the characteristics of typical naïve users accessing the system

along with legal and functional constraints enforced that affect Hospital Management

Application in any fashion.

THE OVERALLDESCRIPTION

Product perspective

Hardware interfaces

Hard disk: The database connectivity requires a hardware configuration that is on-line. This

makes it necessary to have a fast database system (such as any RDBMS) running on high

rpm hard-disk permitting complete data redundancy and backup systems to support the

primary goal of reliability.

The system must interface with the standard output device, keyboard and mouse to interact with

this software.

Software interfaces

Back End: MSAccess

Front End: Microsoft Visual Basic 6.0

Memory Constraints

No specific constraints onmemory.

Operations:

The software allows two modes of operations

The administrator mode allows user to add a new patient, doctor, modify the

existing details of a patient & doctor, view the details of an Patient &doctor.

Product Functions

Patient Details

The user (both administrator and doctor) must have the access to Up-to-date information about

the patient including.

 PatientID

 PatientName

 PatientAge

 PatientAddress

 Admit and DischargeDate

 DoctorDetails

The user (only in administrator mode) must be able to add and view by supplying the

following doctor details.

 Doctor ID

 DoctorName

 DoctorAge

 DoctorAddress

 DoctorQualification

Illness Details

The user (only in doctor mode) must be able to modify the following details of an existing

treatment.

PatientID DoctorID

Illness

Medication

User characteristics

The intended users of this software need not have specific knowledge as to what is the

internal operation of the system. Thus the end user is at a high level of abstraction that

allows easier, faster operation and reduces the knowledge requirement of enduser

The Product is absolutely user friendly, so the intended users can be the naïveusers.

The product does not expect the user to possess any technical background. Any person who

knows to use the mouse and the keyboard can successfully use thisproduct.

Constraints

At the time of adding a new patient and doctor, each must be assigneda unique IDnumber.

The ID numbers for the illness table must match the IDs in the respectivetables

SPECIFICREQUIREMENTS

Logical DatabaseRequirements

There is one database which contains all the necessary information about a patient which

includes patient ID, patient name, age, address, admit and discharge date

There is a database which contains all the necessary information about a doctor which

includes doctor ID, doctor name, age, address, qualification.

There is a database which contains all the necessary information about a treatment which

include Patient ID, doctor ID, illness, medication

FRONT – ENDDESCRIPTION

The front end for the Hospital Management Application (HMA) is designed using

Microsoft Visual Basic 6.0. The front – end contains a user – friendly interface. It has a

welcome screen that provides an option for the user to enter in doctor mode or in

administrator mode. The user has to validate himself using password to enter in

administrator mode. In administrator mode, apart from viewing the details the user can also

add a new patient and doctor by providing details or modify the existing details using the

patient ID and doctorID.

BACK – ENDDESCRIPTION

There are 4 tables. The 1

one maintains login details for all the users. The 2

table

correlates a unique patient ID with his name, age, address, admit and discharge date.. The

3rd table correlates a unique doctor ID with his name, age, address and qualification. The 4

table correlates a doctor ID and patient ID with illness and medication

DATASTRUCTURES

LOGINDETAILS

FIELD NAME

TYPE

CONSTRAINTS

NUMBER

NOT NULL

PASSWORD

TEXT

NOT NULL

PATIENTDETAILS

FIELD NAME

TYPE

CONSTRAINTS

NUMBER

NOT NULL

FNAME

TEXT

NOT NULL

LNAME

TEXT

AGE

TEXT

ADDRESS

TEXT

INDATE

DATE/TIME

OUTDATE

DATE/TIME

DOCTORDETAILS

FIELD NAME

TYPE

CONSTRAINTS

NUMBER

NOT NULL

FNAME

TEXT

NOT NULL

LNAME

TEXT

AGE

NUMBER

ADDRESS

TEXT

QUALIFICATION

TEXT

TREATMENTDETAILS

FIELD NAME

TYPE

CONSTRAINTS

PID

NUMBER

NOT NULL

DID

NUMBER

NOT NULL

ILLNESS

TEXT

MEDICINE

TEXT

E/RDIAGRAM

TESTING

FORM NAME

INPUT

EXPECTED

OUTPUT

ACTUAL

OUTPUT

STATUS

ID and Password

If correct password,

main menu must be

If correct

password, main

menu was

Pass

displayed

MAIN MENU

FORM

Menu Option

Required Form must

Required Form

must be

Pass

displayed

PATIENT

DETAILS FORM

Patient ID or

Patient details

Patient details must be

displayed or updated

to database.

Patient details

was displayed or

updated to

database

Pass

DOCTOR

DETAILS

Doctor ID

Doctor details must be

Doctor details

was displayed

Pass

FORM

displayed

TREATMENT

DETAILS FORM

Patient ID,

Treatment details

must be updated to

database

Treatment

details was

updated to

database

Pass

Doctor ID,

Illness and

Medicines

SAMPLE FORMS

MAIN MENU FORM

PATIENT DETAILSFORM

DOCTOR DETAILSFORM

TREATMENT DETAILS FORM

RESULT

Thus, the Hospital Management System was implemented using the specified front end and

back-end tools.

Ex No: 8 DEVELOPMENTS OF A BLOOD BANK MANAGEMENT SYSTEM

Blood bank is a place where blood bag that is collected from blood donation events is stored in

one place. The term “blood bank” refers to a division of a hospital laboratory where the storage

of blood product occurs and where proper testing is performed to reduce the risk of transfusion

related events.

Online Blood Bank management system is to provide services for the people who need blood by

getting help from the donors who are interested in donating blood for the people. Blood Bank

donation system can collect blood from many donators in short from various sources and

distribute that blood to needy people who require blood. To do all this we require high quality

Web Application to manage those jobs.

Problem Statement

1. The first problem is to search for blood donation records. Staffs of the hospital have to

search one-by-one and it may take a lot of time. Besides that, the paper records can be

lost or undefined.

2. Location of blood donation campaign and planning. Donor usually heard the location for

blood donation campaign from friends or family and cannot plan well for next

donation.

3. The staffs of the hospitals are having difficulty to make report for total blood packet by

monthly basis. Missing and duplicate blood donation information records make the

count inaccurate and this will be problem to detect critical blood demand

4. One of the factors of the public afraid to donate their blood is they believe in myths. The

myths that they always believe are, if they donate their blood they will become weak

and pale. This system hopes to solve that problem by creating more awareness of the

process of blood donation.

System Requirement Specification (SRS)

Purpose:

 The main purpose of this application is to automate the complete operations of the blood bank.

 The intended audience is anyone working at a bloodbank who wants to keep track and maintain

blood donation records Scope:

 The product is titled Blood Bank Management System (BBMS) The product will perform the

following tasks:

 Allow users to register for blood donation

 Allow admin to maintain blood donation records of various different donors and blood group in

a single system.

 Allows super admin to manage admins so that there is no abuse of power.

Definitions, Acronyms and Abbreviations:

BBMS – Blood Bank Management System

References:

 IEEE standard 830-1998 recommended practice for Software Requirements Specifications-

Description.

 IEEE Software Requirements Specifications

Templatehttp://www.cas.master.ca/~carette/SE3M04/2003/files/ srs_template.doc

Overview:

 The SRS contains an analysis of the requirements necessary to help easy design.

 The overall description provides interface requirements for the Blood Bank Management

System, product perspective, hardware interfaces, software interfaces, communication

interface, memory constraints, product functions, user characteristics and other constraints.

 Succeeding pages illustrate the functions of typical users accessing the system along with the

different functions available for the admins and super admins and the responsibilities they

must share to make proper and efficient use of the Blood Bank Management System.

Hardware and Software Requirements Hardware Requirements:

Processor

Intel Core Duo 2.0 GHz or more

RAM

1 GB or More

Hard disk

80GB or more

Monitor

15” CRT, or LCD monitor

Keyboard

Normal or Multimedia

Mouse

Compatible mouse

Software Requirements:

i. XAMPP (Cross Platform(X) for Apache, MySQL, PHP and Perl)

ii. Notepad iii. Google Chrome or Mozilla Firefox or Internet Explorer

Languages Used:

Front End : PHP, HTML, CSS

Back End : MySQL Database Server

Operating System : Windows 7 or above

FRONT-END DESCRIPTION

The proposed system (Blood Bank Management System) is designed to help the Blood

Bank administrator to meet the demand of Blood by sending and/or serving the request for Blood

as and when required. The proposed system gives the procedural approach of how to bridge the

gap between Recipient, Donor, and Blood Banks. The system has a registration process wherein

the user can register as a Donor. The system will provide the admin the option to look at the

details of the Donor and verify the integrity of the user before either accepting or rejecting the

user. The administrator can also alter all the system data. The Super Admin feature has been

added to manage and control all admins so that there is no abuse or corruption of power.

BACK-END DESCRIPTION

There are 7 tables. The 1st table contains admin details such as username and password.

The 2nd table contains information about blood donation camps. The 3rd table contains the user

queries that are sent to the admin. It contains details such as name, email, mobile, subject and

date. The 4th table contains the details of the registered blood donors. The 5th table contains the

table contains the blood requests made by the recipients or hospitals. The req id is the primary

key of the table and it is also auto incremented for every entry in the table. The 7th table contains

all the blood groups. The bg attribute is also the primary key.

DATA STRUCTURE

Admin (admin):

Attributes

Data Type

Constraints

Username

varchar(100)

NOT NULL

Pwd

varchar(100)

NOT NULL

Adminname

varchar(100)

NOT NULL

Camps (camp):

Attributes

Data Type

Constraints

camp id

int(100)

PRIMARY

KEY(AUTO

INCREMENT)

Campname

varchar(500)

NOT NULL

Organisedby

varchar(500)

NOT NULL

City

varchar(100)

NOT NULL

State

varchar(100)

NOT NULL

Detail

varchar(1000)

NOT NULL

Attributes

Data Type

Constraints

Name

varchar(100)

NOT NULL

varchar(100)

NOT NULL

Mobile

varchar(100)

NOT NULL

Subj

varchar(100)

NOT NULL

Date

timestamp(5)

NOT NULL

Donors (registereddonors):

Attributes

Data Type

Constraints

Donorid

int(100)

PRIMARY

KEY(AUTO

INCREMENT)

Name

varchar(100)

NOT NULL

Gender

varchar(10)

NOT NULL

Age

int(3)

NOT NULL

Mobile

varchar(10)

NOT NULL

b_g

varchar(15)

NOT NULL

varchar(100)

NOT NULL

City

varchar(100)

NOT NULL

Super Admin (superadmin):

Attributes

Data Type

Constraints

Username

varchar(100)

NOT NULL

Pwd

varchar(100)

NOT NULL

Adminname

varchar(100)

NOT NULL

Blood Request (requests):

Attributes

Data Type

Constraints

Reqid

int(100)

PRIMARY

KEY(AUTO

INCREMENT)

Name

varchar(100)

NOT NULL

Gender

varchar(100)

NOT NULL

Age

int(3)

NOT NULL

Mobile

varchar(13)

NOT NULL

varchar(15)

NOT NULL

varchar(100)

NOT NULL

Deadline

date

NOT NULL

Detail

varchar(500)

NOT NULL

Blood Group (bloodgroup):

Attributes

Data Type

Constraints

varchar(100)

NOT NULL

DATA FLOW DIAGRAM (DFD) LEVEL 0 DFD:

LEVEL 1 DFD:

LEVEL 2 DFD:

E-R DIAGRAM FOR BLOODBANK:

The E-R Diagram defines 6 different entities and their attributes along with the relationship

between these entities. The entities are Donor, Blood, Blood Bank, Admin, Super Admin and

Recipient. The relationship between these entities are as follows:

• Donor donates Blood

• Blood Bank Stores Blood

• Recipient receives Blood

• Admin Manages Blood Bank

• Super Admin Manages Admin

gender

age

mobile

Blood

group

name

Donor

donate

Blood

city

blood

group

stores

password

username

manages

Blood

Bank

details

deadline

Super

Admin

username

password

name

age

receives

Recipient

gender

mobile

CLASS DIAGRAM:

Sample Forms:

Donor Registration Page:

Request Blood Page:

Camps Page:

About Us Page:

Admin Log in Page:

The Donors Page:

View Requests Page:

Ex No: 9 COVID PATIENTS MANAGEMENT SYSTEM

PROBLEM DEFINITION – This Application is developed to fight the Corona situation

together and stronger.

The COVID Patients Management System is useful for automating the Data Collection of

COVID affected patients and have a track on them.

Doctors/Specialists can enter the details of the patient who has been affected by COVID.

The details include Patient Name, Age, Sex, Mobile number, Address, Date of test,

Doctor.

The Doctors will get an alert once in 15 days in order to track the patient if the age is

less than 35 and 7 days if the age is more than 35. This will help the doctors to have a

Health track on the patients.

The patient will get an automated alert via SMS reminding them to take proper medicine

an diet plan and after the verification of complete curation of the Patient, their data will

automatically be sent to inactive history database

SYSTEM REQUIREMENT SPECIFICATION (SRS)

Purpose:

 The main purpose of this application is to automate the complete operations of the

Hospital in managing Covid Patient Database.

 The intended audience is anyone working at a hospital who wants to keep track and

maintain Covid Patient records

Scope:

1. The product is titled COVID Patients Management system

2. The product will perform the following tasks:

a. Allow doctors to register

b. Allow admin/doctor to maintain Patient records of Covid Test and

3. relevant details

a. Triggers and alert to the doctor 15 days/ 7 days once dependant on the age

4. of the patient

Definitions, Acronyms and Abbreviations:

1. CPMS – COVID Patient Management System

Overview:

The SRS contains an analysis of the requirements necessary to help easy design.

The overall description provides interface requirements for the COVID Patient

Management System, product perspective, hardware interfaces, software interfaces,

communication interface, memory constraints, product functions, user characteristics

and other constraints.

Succeeding pages illustrate the functions of typical users accessing the system along with

the different functions available for the admins and doctors of the hospital.

Hardware and Software Requirements

Hardware Requirements:

Processor : Intel Core Duo 2.0 GHz or more

RAM : 1 GB or More

Hard disk : 40GB or more

Monitor : 15” CRT, LCD or LED monitor

Keyboard : Normal or Multimedia Mouse

: Compatible mouse

Software Requirements:

 XAMPP (Cross Platform(X) for Apache, MySQL, PHP and Perl)

 Notepad

 Google Chrome or Mozilla Firefox or Internet Explorer

Languages Used:

Front End

: PHP, HTML, CSS

Back End

: MySQL Database Server

Operating System

: Windows 7 or above

FRONT-END DESCRIPTION

The proposed COVID Patients Management System is useful for automating the Data

Collection of COVID affected patients and have a track on them.Doctors/Specialists can

enter the details of the patient who has been affected by COVID. The details include

Patient Name, Age, Sex, Mobile number, Address, Date of test, Doctor.The Doctors will

get an alert once in 15 days in order to track the patient if the age is less than 35 and 7

days if the age is more than 35. This will help the doctors to have a Health track on the

patients.The patient will get an automated alert via SMS reminding them to take proper

medicine an diet plan and after the verification of complete curation of the Patient, their

data will automatically be sent to inactive history database

BACK-END DESCRIPTION

There are 4 tables. The 1

table contains Admin/Doctor details such as username

and password. The 2

table contains information about COVID patientssuch as name,

email, mobile,ID,age and date. The 3

table contains the details of the Diet Plans for a

Patient and SMS Management. The 4

table contains the Cured Patients database. Primary

key is the Patient ID.

DATA STRUCTRURE

Doctor/Admin :

Attributes

Data Type

Constraints

Username

varchar(100)

PRIMARY KEY

Pwd

varchar(100)

NOT NULL

Ad/docname

varchar(100)

NOT NULL

Covid Patient :

Attributes

Data Type

Constraints

Name

varchar(100)

NOT NULL

varchar(100)

NOT NULL

Mobile

varchar(100)

NOT NULL

Age

varchar(100)

NOT NULL

Date Admitted

timestamp(5)

NOT NULL

PID

varchar(100)

PRIMARY KEY

Diet Plan :

Attributes

Data Type

Constraints

PID

varchar(100)

PRIMARY KEY

Breakfast

varchar(100)

NOT NULL

Lunch

varchar(100)

NOT NULL

Dinner

varchar(100)

NOT NULL

Cured Patient :

Attributes

Data Type

Constraints

Name

varchar(100)

NOT NULL

varchar(100)

NOT NULL

Mobile

varchar(100)

NOT NULL

Age

varchar(100)

NOT NULL

Date Admitted

timestamp(5)

NOT NULL

PID

varchar(100)

PRIMARY KEY

ER DIAGRAM

DATA FLOW DIAGRAM

LEVEL 0 DFD

LEVEL 1 DFD

LEVEL 2 DFD

SAMPLE SCREENSHOTS

Ex No: 10 RESTAURANT TABLE MANAGEMENT SYSTEM

Restaurant table management system is a application where a customer can pre-book a

table and also will be able to pay their bills through online payment.

In The other end the Hotel management will be able to promote their restaurant and will

receive the customer needs and also the table reservations can be done

Problem Statement

1. The application is useful for the restaurants to provide the customers with the seamless

billing and reservation experience

2. The hotel management team or the manager will be able to look for a free table from

the application once when the customers enter the restaurant and can assign them with

a table free with respect to their group strength

3. The server for that particular table will be able to get the order and will be able to feed

the dishes ordered by the members of the table and will be saved in the database of

that particular table. The server or the management will be able to add or edit the menu

with respect to the members decision

4. Once when the meal is done, the bill will be auto generated once when the server or

the management team clicks on end session and will provide the final bill amount. The

server will then set the table's status to "under cleaning "and once when it is done, the

table will will be back to available status and can be assigned to other customers

entering the restaurant.

System Requirement Specification (SRS)

Purpose:

 The main purpose of this application is to automate the complete operations of the

Restaurant table Management.

 The intended audience is anyone working at a Restaurant who wants to keep track

and maintain Table booking.

Scope:

The product is Restaurant Table Management System (RTMS) The product will

perform the following tasks:

 Allow users to book the table

 Allow admin to maintain reservation of tables from different customers and

pay the bill in a single system.

 Allows super admin to manage admins so that there is no abuse of power

.Definitions, Acronyms andAbbreviations:

RTMS– Restaurant Table Management System

References:

 IEEE standard 830-1998 recommended practice for

Software

 RequirementsSpecifications-Description.

 IEEE Software Requirements Specifications

Templatehttp://www.cas.master.ca/~carette/SE3M04/2003/files/ srs_template.doc

Overview:

 The SRS contains an analysis of the requirements necessary to help easy design.The

overall description provides interface requirements for the Restaurant Table

Management System, product perspective, hardware interfaces, software interfaces,

communication interface, memory constraints, product functions, user characteristics

and otherconstraints.

 Succeeding pages illustrate the functions of typical users accessing the system along with

the different functions available for the admins and super admins and the

responsibilities they must share to make proper and efficient use of the Restaurant

Table Management System.

Hardware and Software Requirements Hardware Requirements:

Processor : Intel Core Duo 2.0 GHz or more

RAM : 1 GB or More

Hard disk : 80GB or more

Monitor : 15” CRT, or LCD monitor

Keyboard : Normal or Multimedia

Mouse : Compatible mouse

Software Requirements: iv. XAMPP (Cross Platform(X) for Apache, MySQL, PHP

and Perl)

v. Notepad vi. Google Chrome or Mozilla Firefox or Internet Explorer

Languages Used:

Front End

: PHP, HTML, CSS

Back End

: MySQL Database Server

Operating System

: Windows 7 or above

FRONT-END DESCRIPTION

The proposed system (Restaurant Table Management System) is designed to help

the customers book the table and pay the bill . The proposed system gives the procedural

approach of how to bridge the gap between Customer, hotel management and bank . The

system has a registration process wherein the user can register as a Customer. The system

will provide the admin the option to look at the details of the customer and verify the

integrity of the hotel management before either accepting or rejecting the table reservation.

The administrator can also alter all the system data. The Super Admin feature has been

added to manage and control all admins so that there is no abuse or corruption of power.

BACK-END DESCRIPTION

There are 7 tables. The 1st table contains admin details such as username and

password. The 2nd table contains information about Registered Restaurants. The 3rd

table contains the user queries that are sent to the admin. It contains details such as name,

email, mobile, subject and date. The 4th table contains the details of the registered

Customers . The 5th table contains the login credentials of the super admins whose main

function is to manage the other admins. The 6

table contains the Food requests made by

the customer and Restaurants. The req id is the primary key of the table and it is also auto

incremented for every entry in the table. The 7th table contains all the nearby available

hotels. The bg attribute is also the primary key.

DATA STRUCTURE

Admin (admin):

Attributes

Data Type

Constraints

Username

varchar(100)

PRIMARY

INCREMENTKEY(AUTO)

Pwd

varchar(100)

NOT NULL

Adminname

varchar(100)

NOT NULL

Restaurant Names (Hotel):

Attributes

Data Type

Constraints

Restaurant ID

int(100)

PRIMARY

KEY(AUTO

INCREMENT)

Restaurant name

varchar(500)

NOT NULL

Manager name

varchar(500)

NOT NULL

City

varchar(100)

NOT NULL

State

varchar(100)

NOT NULL

Detail

varchar(1000)

NOT NULL

Attributes

Data Type

Constraints

Name

varchar(100)

NOT NULL

varchar(100)

NOT NULL

Mobile

varchar(100)

PRIMARY

KEY(AUTO

INCREMENT)

Subj

varchar(100)

NOT NULL

Date

timestamp(5)

NOT NULL

Customors (registeredcustomers):

Attributes

Data Type

Constraints

Customerid

int(100)

PRIMARY

KEY(AUTO

INCREMENT)

Name

varchar(100)

NOT NULL

Gender

varchar(10)

NOT NULL

Age

int(3)

NOT NULL

Mobile

varchar(10)

NOT NULL

b_g

varchar(15)

NOT NULL

varchar(100)

NOT NULL

City

varchar(100)

NOT NULL

Super Admin (superadmin):

Attributes

Data Type

Constraints

Username

varchar(100)

PRIMARY

KEY

AUTO

INCREMENT)

Pwd

varchar(100)

NOT NULL

Adminname

varchar(100)

NOT NULL

Table Reservation (Pre booking table ):

Attributes

Data Type

Constraints

Reqid

int(100)

PRIMARY

KEY(AUTO

INCREMENT)

Name

varchar(100)

NOT NULL

Gender

varchar(100)

NOT NULL

Age

int(3)

NOT NULL

Mobile

varchar(13)

NOT NULL

Headcount

int(3)

NOT NULL

varchar(100)

NOT NULL

Deadline

date

NOT NULL

Detail

varchar(500)

NOT NULL

DATA FLOW DIAGRAM (DFD) LEVEL 0 DFD:

LEVEL 1 DFD

LEVEL 2 DFD

E-R DIAGRAM FOR TABLE MANAGEMENT SYSTEM:

The E-R Diagram defines 6 different entities and their attributes along with the relationship

between these entities. The entities are Cashier, Customer, Chef, Taken by, Waiter,

Restaurant.

The relationship between these entities are as follows:

 Customer reserves Table

 Restaurant receives the order

 Confirms the table

 Waiter Manages the order

 Waiter serves the food

 Customer pays the bill

7. Sample Forms

Ex No: 11 EVENT MANAGEMENT SYSTEM

Event management is the application of project management to the Creation and

Development of large scale events such as festivals, Wedding ceremonies, formal parties.

People that are need to find or book online event halls and or willing to see the packages

and timing slots online about halls. They will able to get all this information through this

system. To get success in the event management business, user should have strong network

contacts of service provider. These contacts are essentially providers of specific services

who can be mobilized quickly to participate in any given event. To make an event

successful event Manager needs different service provider like Sound systems services,

Lighting providers, Canteen services, stage construction and so on.

Problems statement:

 In any event many service providers work simultaneously and it is very hard to manage

these providers.

 It is also important for event organizer that he has all the contacts details of these service

Providers so that he can contact them any time to plan an event at given time.

 In present system Event Company has to do all management work manually.

 They keep all payment information on papers.

 There is no system to check the past expenses on any event.

 To do this they have to check payment register

 This task is very time consuming and tiresome.

so this system helps the event management company to manage their paper work online

and they

can also retrieve report of last event they have completed

Dependencies/ External Systems

Following are the tools / technologies, on which our system depends for its completion,

Programming language: PHP

Front-End: HTML, CSS, BOOTSTRAP(framework of CSS ANS JS)

Hardware interface: 512 MB RAM, WINDOWS 7/8

Database: MySql

XAMPP (Apache MySql PHP)

MySQL server is an open source relational database management system

which is used to store the database using SQL queries. In this project data

of halls, wedding lawns and data of accounts are stored in it. Tools: Visual

Studio

Frame work: MVC

MVC (Model View Controller) is used for implementing user interface on computers.

Product:

cyber cash

The CyberCash Secure Payment System is a complete system for conducting financial

transactions on the Internet. It accepts both credit card payments and cash/coin

transactions. The CyberCash system is a great solution for any Web site that wants to

accept electronic payment for goods or services

Requirements

Functional

Requirement

Registration:

To enter into this site user has to register himself first.

Requirements of registration are first name, last name,

user name, email-id, password, confirm password etc.

User Login:

 The System provides facility to login into the system.

 Enter username and password

 User Profile page

Select the Event:

 The user can select the event and also select payment method.

Forgot Password

 The user can send reset link to the mail id to reset password.

 Input: Email id

 Output: Reset link send to Email id.

Logout:

 The system provides the facility to logout from the site

 Input : Select logout option

 Output : Logout from the system

 Processing : User will logout

Online packages:

 Online various payment packages will available to see.

Time Slots:

 Time slots for availability of a place or venue on which event going too held.

Notification/updates:

 User will get to know any notification, recent update or important massages through e-

mail.

Non-Functional

Requirement 1.

Performance

Requirements:

 The system need to be reliable

 If unable to process the request then appropriate error message

 Web pages are loaded within few seconds

2. Safety Requirements:

 The details need to be maintained properly

 Users must be authenticated The database must be kept backed up

3. Security Requirements:

 After entering the password and user id the user

 can access his profile

 The details of user must be safe and secure

 Sharing of details Data Requirements:

Minimum 1GB needed to store our database.

512MB RAM is also needed to install our whole system.

External Requirements:

How will our system connect to other software/components?

External requirements are following;

 To get important notification through E-mail, user must have to provide and email

address.

 For online payment; for example using cyber cash customer will provide account

number.

DATA FLOW DIAGRAM

Data Flow Diagram level 0:

Data Flow Diagram level 1:

Data Flow Diagram Level 2

Data Dictionary User:

ATTRIBUTES

DATA TYPE

CONSTRAINTS

U_id

Varchar(100)

PRIMARY KEY

U_Name

Varchar(100)

Not null

U_Contact

Varchar(100)

Not null

U_Location

Varchar(100)

Not null

U_Email

Varchar(100)

Not null

User Request:

Name

Data Type

CONSTRAINTS

UR_Categories

Varchar(100)

NOT NULL

UR_Service

Varchar(100)

NOT NULL

UR_Location

Varchar(100)

NOT NULL

Account:

Name

Data

Type

Constraints

AC_ID

Integer(4)

PRIMARY

KEY

AC_Password

String(30)

NOT NULL

AC_Email

String(20)

NOT NULL

Admin:

Name

Data

Type

Constraints

AD_ID

Integer(5)

PRIMARY

KEY

AD_Name

String(30)

NOT NULL

AD_Password

String(25)

NOT NULL

SCREEN SHOTS:

Home:

User login

Change password

Add sponsor:

Ex No: 12 CRIME REPORTING SYSTEM

ABSTRACT:

 The aim of the project is to develop an online crime report and managing system which is

easily accessible to the public.

 This System registers the complaints from people through online and it will also helpful

to police department in catching criminals, in system and person can give any

complaint at any time.

PROBLEM STATEMENT:

 This Application is used to develop a web based program using which people can report

crime on online.

 There will be an ‘SOS ’capability in which, the user can press a button and his/her

location will be sent to the nearest Police station.

 There will be a separate component for the accident victims so that FIR will be registered

fast and treatment will be started as soon as possible.

 In the current system user information will be kept confidential and users complain will

be forwarded to the nearest police station.

 It will search the address using IP address and then forwards the message to the police

location from where the message has been received.

 We intend to create a project which will helps to bridge the gap between the police

department and the common man.

 The main site will be maintained by the admin (from the police) who will then notify the

user if the FIR has been registered and the necessary action has been taken.

SYSTEM REQUIREMENT SPECIFICATION (SRS):

Purpose:

The main purpose of this application is to automate the complete operations of the

Crime Reporting System. The intended audience is anyone working at a Crime

Reporting System who wants to keep track and maintain the Crime records

Scope:

The product is titled Crime Reporting System System

(CRS) The product will perform the following tasks:

 Allow users to register for Complaints.

 Allow admin to maintain the records of various different users and action taken by the

police officers in a single system.

 Allows super admin to manage admins so that there is no abuse of power.

Definitions, Acronyms and Abbreviations:

 CRS – Crime Reporting System(CRS)

Overview:

 The SRS contains an analysis of the requirements necessary to help easy design.

 The overall description provides interface requirements for the Crime Reporting System,

product perspective, hardware interfaces, software interfaces, communication interface,

memory constraints, product functions, user characteristics and otherconstraints.

 Succeeding pages illustrate the functions of typical users accessing the system along with

the different functions available for the admins and super admins and the

responsibilities they must share to make proper and efficient use of the Crime

Reporting System

Hardware and Software Requirements

Hardware requirements:

The database connectivity requires a hardware configuration that is on-line. This makes it

necessary to have a fast database system running on high rpm hard disk permitting

complete data redundancy and back-up systems to support the primary goal of reliability.

 Processor : Intel Core Duo 2.0 GHz or more

 RAM : 1 GB or More

 Hard disk : 80GB or more

 Monitor : 15” CRT, or LCD monitor

 Keyboard : Normal or Multimedia

 Mouse : Compatible mouse

Software Requirements: vii. XAMPP (Cross Platform(X) for Apache, MySQL, PHP

and Perl)

viii. Notepad ix. Google Chrome or Mozilla Firefox or Internet Explorer

Languages Used:

Front End

: PHP, HTML, CSS

Back End

: MySQL Database Server

Operating System

: Windows 7 or above

FRONT-END &BACK-END DESCRIPTION

FRONT-END DESCRIPTION:

The proposed system (Crime Reporting System) is designed to help the Crime Reporting

administrator to meet the sending and/or serving the request for complaints as and when

required. The proposed system gives the procedural approach of how to bridge the gap

between public, police officer, and the admin. The system has a registration process

wherein the user can register to raise the complaints. The system will provide the admin

the option to look at the details of the complaints and verify the integrity of the user before

either accepting or rejecting the user. The administrator can also alter all the system data.

The Super Admin feature has been added to manage and control all admins so that there is

no abuse or corruption of power.

BACK-END DESCRIPTION:

There are 9 tables. The 1

table contains User details such as username, password and so

on.The 2nd table contains the details of users first information report(FIR) that are sent to

the admin. The 3rd table contains the details of users about the missing person. The 4th

table contains admins login details. The 5th table contains the admins response for the user

report.The 6th table contains police officer login details. The 7th table contains the officer's

response for the user report to the admine and the user.The 8th table contains police officer

and the user.

DATA STRUCTURE:

USER DETAILS:

Attributes

Data Type

Constraints

Report ID

int(100)

PRIMARY

KEY(AUTO

INCREMENT)

User ID

varchar(100)

FOREIGN KEY

Phone Number

varchar(100)

NOT NULL

Email ID

varchar(100)

NOT NULL

Address

varchar(100)

NOT NULL

Aadhar card number

varchar(100)

NOT NULL

City

varchar(100)

NOT NULL

FRIST INFORMATION REPORT :

Attributes

Data Type

Constraints

Report No

int(100)

PRIMARY KEY(AUTO

INCREMENT)

Complaint ID

varchar(100)

FOREIGN KEY

Username

varchar(100)

NOT NULL

Report Details

varchar(100)

NOT NULL

Address

varchar(100)

NOT NULL

Date and time of

the Incident

Datetime

NOT NULL

Picture/Vedio

upload

varchar(100)

NOT NULL

Phone No

varchar(100)

NOT NULL

City

varchar(100)

NOT NULL

MISSING PERSON REPORT :

Attributes

Data Type

Constraints

Report No

int(100)

PRIMARY KEY(AUTO

INCREMENT)

Name

varchar(100)

NOT NULL

Complaint ID

varchar(100)

FOREIGN KEY

Age

varchar(100)

NOT NULL

Missing date

varchar(100)

NOT NULL

Contact no

varchar(100)

NOT NULL

Alter contact

varchar(100)

NOT NULL

Picture/Video

upload

varchar(100)

NOT NULL

City

varchar(100)

NOT NULL

Police Officer (login):

Attributes

Data Type

Constraints

Username

varchar(100)

NOT NULL

Officer ID

varchar(100)

NOT NULL

Password

varchar(100)

NOT NULL

Police Officer Page:

Attributes

Data Type

Constraints

Report No

int(100)

PRIMARY

KEY(AUTO

INCREMENT)

User Name

varchar(100)

NOT NULL

Action Taken

varchar(100)

NOT NULL

Status Upload

varchar(100)

NOT NULL

Contact No

varchar(100)

NOT NULL

Message

varchar(200)

NOT NULL

Admin (login):

Attributes

Data Type

Constraints

Report No

int(100)

PRIMARY

KEY(AUTO

INCREMENT)

Email ID

varchar(100)

NOT NULL

Password

varchar(100)

NOT NULL

Admin Page:

Attributes

Data Type

Constraints

Report No

int(100)

PRIMARY

KEY(AUTO

INCREMENT)

Police

Officer ID

varchar(100)

FOREIGN KEY

Status of

Report

varchar(100)

NOT NULL

Contact No

varchar(100)

NOT NULL

Message

varchar(200)

NOT NULL

Supreme Admine (details):

Attributes

Data Type

Constraints

Name

varchar(100)

NOT NULL

Password

varchar(100)

NOT NULL

Officer ID

varchar(100)

NOT NULL

Supreme Admine (page):

Attributes

Data Type

Constraints

Report No

int(100)

PRIMARY KEY(AUTO

INCREMENT)

Admin ID

varchar(100)

NOT NULL

Status

varchar(100)

NOT NULL

Message

varchar(200)

NOT NULL

DATA FLOW DIAGRAM(DFD):

LEVEL 0 DFD:

Supre

admin

ADMIN

Police

Officer

User/Public

LEVEL_1_DFD:

view/updat

edit/view/updat

estatus

LOGI

POLICE

LOG

Admin

complaint

details

upload

action

the

pending

view

complaint

LOG

OUT

LOG

OUT

LEVEL

DFD:

User

LOG

Pending

report

Complaints

report

Action

taken

details

the

pending

LOG

OUT

100

CITIZEN/USERS :

The Users has the permission to add complaint, crime report, missing person details, edit

account, see complaint status send message and also change password.

101

Admin Features :

Admin has the permission to see users, block users, see user complaints, crimes & can

reply. He /She can add, delete, update and view the most wanted persons, missing

persons, emergency complaint, complaints status, query, feedback and change

password

102

Police Officer:

By Login the police officer can view the complaints, update the complaint status and the

emergency complaints. Also he/she can Inquire the complaint.

CONCLUSION:

The automated Reporting System is more functional because of people automatically can

report crimes around them in picture or video format to the crime authority .

RESULT:

Thus, the Crime Reporting System was implemented using the specified front end and back

endtool.

103

Ex No: 13 BOOK RESALE APPLICATION

PROBLEM DEFINITION

There are many peoples who are interested in reading books. However, not many of them

are regular in reading books because the new books are costly This project is aimed to

developing an Online old used book information. This project Book management System

explains about how Book Shops works with the computer application when any customers

buy books from the store. Book management system is a project which aims in developing

a computerized system to maintain all the books. Books can be searched by their Title,

Description or Author and also books can be seen in appropriate categories. Each book is

added with a unique Identification number and other details including a Shelf Number

which helps to locate the book. We can also use Google Books to fetch details of a book

from Internet. A cover image and PDF eBook can also be attached with the Book details.

The Books can be issued and Submitted in a fast manner. The Library members can be

managed more efficiently. We can easily get information like who took a particular book or

which are the books taken by a specific Library members

INTRODUTION

In the world of software development there lots of improvement in the area of

Architectural design and principles. The philosophies and implementation details are

changing as the people guiding the development of the application. In this fantastic and yet

sometimes complex world of software development there are some tried and true

architecture patterns and software development guidelines employed by most architects.

Also your design must have an ability to turn towards innovation instead of lending itself

to common practices. Web services are one such area where architects must lean on their

creative side and hope that their solutions are still successful. In this report we will explain

an exciting voyage down the road of Web services application. From requirements to use

cases, to database design, to component frameworks, to user interfaces, we will cover each

and every aspect of system design required to build an application with collaborative Web

services. The reason why we selected online Bookstore web service is everybody walking

down the street has some idea about bookstores. The objective of this project is to develop

an ebook store where books can be bought from the comfort of home through the Internet.

An online book store is a virtual store on the Internet where customers can browse the

catalog and select books of interest. The selected books may be collected in a shopping

cart. At checkout time, the items in the shopping cart will be presented as an order. At that

time, more information will be needed to complete the transaction. Usually, the customer

will be asked to fill or select a billing address, a shipping address, a shipping option, and

payment information such as credit card number. An email notification is sent to the

customer as soon as the order is placed.

SYSTEM REQUIREMENT

Below are the tools, languages and software that were used to develop a Book Resale

Application System:

104

HARDWARE REQUIREMENTS

System : Pentium IV 2.4 GHz.

Hard Disk : 40 GB.

Floppy Drive : 1.44 Mb.

Monitor : 15 VGA Colour.

Mouse : Logitech.

Ram : 512 Mb.

SOFTWARE REQUIREMENTS

Operating system : Windows XP.

Coding Language : JAVA

Data Base : MYSQL

IDE : Net Beans

DATA FLOW DIAGRAM

LEVEL 1:

OWNER

CUSTOMER

DATABASE

LEVEL2

OWNER

Upload

Data

SEND

MAIL

105

Level 3:

Level 4:

Send

Key

User

USER

Add

cart

Registration

LOGOUT

View

book

view

book

View

history

Add

book

LOGOUT

Admin

Buy

View

categort

book

Add

cart

Logout

Customer

106

TESTING

System Testing

The purpose of testing is to discover errors. Testing is the process of trying to

discover every conceivable fault or weakness in a work product. It provides a way to check

the functionality of components, sub-assemblies, assemblies and/or a finished product It is

the process of exercising software with the intent of ensuring that the

Software system meets its requirements and user expectations and does not fail in an

unacceptable manner. There are various types of test. Each test type addresses a specific

testing requirement.

Unit testing

Unit testing involves the design of test cases that validate that the internal program logic

is functioning properly, and that program inputs produce valid outputs. All decision

branches and internal code flow should be validated. It is the testing of individual software

units of the application .it is done after the completion of an individual unit before

integration. This is a structural testing, that relies on knowledge of its construction and is

invasive. Unit tests perform basic tests at component level and test a specific business

process, application, and/or system configuration. Unit tests ensure that each unique path

of a business process performs accurately to the documented specifications and contains

clearly defined inputs and expected results.

SCREENSHOTS

HOME

107

ADMIN

108

USER

109

USER REGISTRATION

110

111

RESULT

Thus the Book Resale Application System was implemented using the specified front end

and back end tools.

112

113

Ex No: 14 TOURS AND TRAVELS MANAGEMENT SYSTEM

Abstract:

The Tours and Travel Management System is a web based application. The main

purpose of “Tours and travels management system” is to provide a convenient way

for a customer to book hotels, flight, train and bus for tour purposes.

 The main objective of this project is to develop a system that automates the processes and

activities of a travel agency. In this project, we will make an easier task of searching

places and for booking train, flight or bus.

 In the present system, a customer has to approach various agencies to find details of

places and to book tickets. This often requires a lot of time and effort.

 We provide approach skills to critically examine how a tourist visits and its ability to

operate in an appropriate way when dealing with the consequences of tourism, locally,

regionally, and nationally including visitor security and ecological influences.

 It is tedious for a customer to plan a particular journey and have it executed properly.

 The project ‘Tours and Travels Management System’ is developed to replace the

currently existing system, which helps in keeping records of the customer details of

destination as well as payment received.

PROPOSED SYSTEM:

The proposed system is a web based application and maintains a

centralized repository of all related information. The system allows one to easily

access the relevant information and make necessary travel arrangements. Users

can decide about places they want to visit and make bookings online for travel

and accommodation

EXISTING SYSTEM:

In the present system a customer has to approach various agencies to find detailsof

places and to book tickets This often requires a lot of time and effort. A customermay not

get the desired information from these office and often the customer may be misguided

SCOPE OF PROJECT:-

 The Website is developed based on real life. It is very helpful in business applications.

 Today's extremely exhausting work environment dictates that individuals requires

 some joyful holiday. The website will provides a stress-free joyful refreshing holidays

 with cost competitive and customized packages according to their requirements

 The Website is developed based on real life. It is very helpful in business applications.

 Today's extremely exhausting work environment dictates that individuals requires some

joyful holiday. The website will provides a stress-free joyful refreshing holidays with

cost competitive and customized packages according to their requirements

114

HARDWARE REQUIREMNTS:-

 RAM: 8GB

 SYSTEM TYPE: x64 based processor PROCESSOR: Intel Core 1.50Ghz

SOFTWARE

REQUIREMENTS:

 OPERATING SYSTEM:

Windows10

 FRONT END: ASP.NET

 BACK END: MYSQL

INTRODUCTION

 Tour & Travel is an irresistible word when it comes totour and travel packages. Weoffer

tour and travel services including ticket bookings, hotel reservations,rental carservices,

holiday tour packages, domestic tour packages.

 Whether you're looking for aweekend getaway to relax and indulge, a special holiday

with friends and family, atrip to your favorite chill out spot or a new adventure, you've

come to the right place.Tour & TravelTravel offers great deals and discounts on flights,

railways, hotels,holiday packages, car rental and travel activities everything you need

to plan, shop

Modules of travel and tour management system:-

User Management:

a. Login.

b. User profile.

c. Update information.

d. Role based rights.

115

Dataflow Diagram:

LEVEL1:

116

LEVEL 2:

DATABASETABLE:-

Fieldname

Data type

Length

Key

Username

Varchar

Primary key

Password

Varchar

Status

Varchar

User Registration:-

Fieldname

Data type

Length

Key

USERNAME

Varchar2(4000)

-Primary

NAME

Varchar2(4000)

ADDRESS

Varchar2(4000)

PHONENO

Varchar2(66)

YES

PINCODE

Varchar2(66)

YES

Varchar2(4000)

YES

117

HOTELRESULT:

Fieldname

Data Type

Length

Key

IMAGE

BLOB

YES

HOTELNAME

Varchar2(4000)

YES

HOTELADDRESS

Varchar2(4000)

YES

HOTELTYPE

Varchar2(4000)

YES

HOTELPRICE

Varchar2(4000)

YES

FACI

Varchar2(4000)

YES

TOURBOOK:

Fieldname

Data Type

Length

Key

REQNO

Varchar2(40)

NAME

Varchar2(40)

YES

ADDRESS

Varchar2(40)

YES

PHONENO

Varchar2(40)

YES

EMAILID

Varchar2(40)

YES

TOURNAME

Varchar2(40)

YES

CANTRY

Varchar2(40)

YES

TORIST

Varchar2(40)

YES

ARRIVEL

Varchar2(40)

YES

RETURN

Varchar2(40)

YES

HOTELNAME

Varchar2(40)

YES

ROOMS

Varchar2(40)

YES

ADULTSC

Varchar2(40)

YES

CHILDERN

Varchar2(40)

YES

DETAIL

Varchar2(40)

YES

TOUR-STATUS

Varchar2(4000)

YES

HOTEL-

STATUS

Varchar2(4000)

YES

ROOMNO

Varchar2(4000)

YES

118

CARBOOKING:

Fieldname

Data Type

Length

Key

REQNO

Varchar2(40)

-Primary

NAME

Varchar2(40)

YES

ADDRESS

Varchar2(40)

YES

PHONENO

Varchar2(40)

YES

EMAILID

Varchar2(40)

YES

VIHICLE

Varchar2(40)

YES

PICUP

Varchar2(40)

YES

CANTRY

Varchar2(40)

YES

PASSENGER

Varchar2(40)

YES

ARRIVAL

Varchar2(40)

YES

RETURN

Varchar2(40)

YES

CAR

Varchar2(40)

YES

ADMIN:-

119

PLACE LIST:-

120

CONCLUSION:-

 The automated Tours and Travels Management System is more fuction because of people

can get their package to the authority

RESULT:-

 Thus, the Tours and Travels Management System was implemented using the specified

front and back end tool

121

Ex No: 15 APPLYING DATA MINING IN CYBER CRIME

PROBLEM DEFINITION

 Our project is based on the reliability and availability of network services are being

threatened by the growing number of Denial-of-Service (DoS) attacks.

 Effective mechanisms for DoS attack detection are demanded.

 Investigate and extract second-order statistics from the observed network traffic records.

 These second-order statistics extracted by the proposed analysis approach can provide

important correlative information hiding among the features.

 By making use of this hidden information, the detection accuracy can be significantly

enhanced.

INTRODUCTION

Cloud computing is a recent technology that aims at providing access to resources instantly

as per the needs of the end users. Cloud enables its customers to make use of the resources

that are widely distributed in the internet to perform computations without installing in

their own PC’s and has to pay only for the service they consumed. All the computational

requirements will be taken care of by the cloud service providers and hence all the

complexities involved will be hidden from the user. NIST identifies the five key

characteristics of cloud computing as on- demand self- service, resource pooling, broad

network access, rapid elasticity and measured service.

Cloud offers services in three basic forms namely infrastructure (IaaS),platforms (PaaS)

and Software (SaaS) and is on the stage of evolution to provide everything as a service

(XaaS). As large magnitudes of data are moving onto the cloud, the attackers are keener to

exploit the vulnerabilities associated with cloud and thereby to steal the sensitive data.

Among the various threats tocloud computing, Denial of Service(DoS) attacks can prove to

be the deadliest attack and even the Cloud Security Alliance has identified DoS attack as

one of the nine major threats. In DoS attack, the intruder overloads the target system with

service requests so that it cannot respond to any further requests and hence resources will

be made unavailable to its users. Distributed Denial of Service(DDoS) attack makes use of

several compromised machines called zombies to launch DoS attack on the target machine

and the service is disrupted or delayed.DDoS attacks are getting more frequent these days

and hence proper intrusion detection systems has to be deployed.

This project discusses the 2 various kinds of DDOS attacks possible and the various

countermeasures that need to be followed to avert such attacks.

In computing,a denial-of-service attack (DoS attack) is a cyber-attack where the perpetrator

seeks to make a machine or network resource unavailable to its intended users by

temporarily or indefinitely disrupting services of a host connected to the Internet. Denial of

service is typically accomplished by flooding the targeted machine or resource with

superfluous requests in an attempt to overload systems and prevent some or all legitimate

requests from being fulfilled.

122

In a distributed denial-of-service attack (DDoS attack), the incoming traffic flooding the

victim originates from many different sources.

This effectively makes it impossible to stop the attack simply by blocking a single source.

A DoS or DDoS attack is analogous to a group of people crowding the entry door or gate to

a shop or business, and not letting legitimate parties enter into the shop or business,

disrupting normal operations. Criminal perpetrators of DoS attacks often target sites or

services hosted on highprofile web servers such as banks or credit card payment gateways.

Revenge, blackmail and activism can motivate these attacks.

SYSTEM REQUIREMENTS

Below are the tools, languages and software that were used to develop a Book Resale

Application System:

HARDWARE REQUIREMENTS

Processor

Intel Core 2

Speed

1.1 GHz

Hard Disk

250 GB.

Monitor

SVGA

Mouse

Optical

Ram

1GB

SOFTWARE REQUIREMENTS

Operating

System

Windows95/98/2000/XP/7.

Operating

System

Application

Server

Tomcat6.0/7/8.X.

Application

Server

Front End

&CSS

Java,HTML

Front End

&CSS

Scripts

JavaScript.

Scripts

Server side

Script

Java Server Pages.

Server side

Script

IDE

Eclipse/ Net beans

IDE

Back End

MYSQL 5.0/ Heidi SQL 8.1

Back End

123

DATA FLOW DIAGRAM

TESTING

SYSTEM TESTING

The purpose of testing is to discover errors. Testing is the process of trying to discover

every conceivable fault or weakness in a work product. It provides a way to check the

functionality of components, sub assemblies, assemblies and/or a finished product ,it is the

process of exercising software with the intent of ensuring that the software system meets

its requirements and user expectations and does not fail in an unacceptable manner. There

are various types of test. Each test type addresses a specific testing requirement.

UNIT TESTING

Unit testing involves the design of test cases that validate that the internal program logic is

functioning properly, and that program inputs produce valid outputs. All decision branches

and internal code flow should be validated. It is the testing of individual software units of

the application .It is done after the completion of an individual unit before integration. This

is a structural testing, that relies on knowledge of its construction and is invasive. Unit tests

perform basic tests at component level and test a specific business process, application,

and/or system configuration. Unit tests ensure that each unique path of a business process

performs accurately to the documented specifications and contains clearly defined inputs

and expected results.

124

SCREENSHOTS

HOME

ADMIN

125

USER

USER REGISTRATION

RESULT

Thus, the Book Resale Application System was implemented using the specified

front end andback end tools.